Logic simulators exist that utilize one or more processors to simulate a logic design to be emulated. At one end of the spectrum are those simulators having no parallelism. In other words, a single processor executes a program in series to simulate a design. Such simulation systems are extremely slow. At the other end of the spectrum are those simulators having a high degree of parallelism. These simulation systems have the ability to run extremely fast, as many of the tasks performed by these simulation systems may be performed simultaneously.
However, high parallelism comes at a price. First, logic simulation systems with a large number of parallel processors must find a way to interconnect the processors so that they may communicate with one another. However, the larger the number of processors, the more complex the interconnection network; the number of interconnections may rise exponentially with the number of processors. A tradeoff is to reduce the possible ways that the processors may interconnect with one another. While this reduces the cost and size of the system, it also reduces its capacity and speed.
A second price of high parallelism is network conflict. The greater the number of parallel processors, the more likely signals are going to cross and conflict with one another as they propagate through the interconnection network. Conflicts may be reduced, but not always easily prevented, especially where asynchronous signals and multiple clocks are part of the design. In such designs, it is very difficult to predict when all of the signals are to be sent; the timing tasks in the design simulation are not deterministic and must be determined on the fly during runtime.
A third priced of high parallelism is efficiency. When multiple parallel processors are used to simulate a user design, the design is divided into pieces and distributed among the processors. However, it is very difficult to distribute the design pieces without creating inefficiencies. Sometimes processors have to wait on data from other processors before continuing. This waiting not only inherently slows down the system, but also requires additional program instruction space to store wait or no-operation commands.